Synchronize EIP-4844 cryptography with consensus specs #5649
Conversation
github-actions
bot
added
c-update
All tests passed; auto-merging...(pass) eip-4844.md
|
I was thinking that part of the appeal of this approach is that the link will always point to the latest version of the functions, and as long as the function names remain the same we will not have to change the EIP-side at all. Do you think that's too flexible? |
asn-d6
force-pushed
the
eip4844-crypto-catchup
branch
from
651cbec
to
8aef882
Compare
Thinking about this again, I think doing it one step at a time is fine. I have force-pushed a new commit 851d380, that pins down a specific revision (current consensus-specs HEAD) for all functions cited. This should prevent any sort of rug pulling from the consensus-specs side. This took a while because I wanted to make sure that all hovering EIP4844 crypto-related changeshave been merged to consensus-specs, which is now the case. Please let me know what else I can do on this one :) |
This commit introduces various fixes and improvements to the KZG-related code of EIP-4844. This commit brings the EIP code up-to-speed with the consensus-specs code. Note that instead of updating the cryptographic functions we instead link to the relevant parts of the consensus-specs repository. This is done to avoid code duplication between the two repositories -- an approach that seems prudent in cross-execution-and-consensus situations like EIP-4844.
asn-d6
force-pushed
the
eip4844-crypto-catchup
branch
from
8aef882
to
851d380
Compare
|
Hey @SamWilsn is it okay to manually merge while we wait for the walidator to accept the CL spec links, or are we still trying to come to agreement on that? |
|
I'm going to override The editors are still debating the specifics, but it appears that links to the consensus specs which refer to a specific commit will be acceptable. In order to avoid any further confusion among implementation teams currently working on EIP-4844, I'm going to merge these changes as I have verified that each link is to a specific revision of the spec. We can continue debating the exact external link policy and we will review the current state of things as this EIP moves forward to review. |
This commit introduces various fixes and improvements to the KZG-related code of EIP-4844. This commit brings the EIP code up-to-speed with the consensus-specs code. Note that instead of updating the cryptographic functions we instead link to the relevant parts of the consensus-specs repository. This is done to avoid code duplication between the two repositories -- an approach that seems prudent in cross-execution-and-consensus situations like EIP-4844.
So... at some point back in June we updated the consensus side of 4844 to be executable. This resulted in various fixes and improvements for the cryptographic parts of the consensus code.
These updates were never ported back to EIP land because the code was quite unstable and we wanted to minimize any duplicate overhead between EIP and consensus review processes. This means that the EIP was out of date for the past months...
These days, the 4844 cryptographic code seems relatively stable, so this commit updates the EIP. Also, with the merge coming up, more devs will start looking at 4844 code, and hence having the code be up to date is imperative.
Note that instead of updating the cryptographic functions we instead link to the relevant parts of the consensus-specs
repository. This is done to avoid code duplication between the two repositories -- an approach that seems prudent in
cross-execution-and-consensus situations like EIP-4844. I imagine that people might not like this approach, but in that case, I would appreciate feedback on alternative approaches we could take.
Cheers!